User's Choice Windows CD/User's Choice Windows CD (CMS Software)(1993).iso/windows5/winnet.zip/NOVTCP.TXT

Text File | 1990-03-27 | 14KB | 295 lines

         CONCURRENT NOVELL NETWARE AND TCP/IP USAGE: A CASE STUDY

    Wesleyan University is an active networking site, heavily using
Bitnet, NSFnet, and local area Ethernets.  Recently we started
implementing local PC and Macintosh networks using Novell Netware.  Since
TCP/IP is our universal protocol, we wanted all PCs on the Novell network
to have full concurrent access to Telnet and FTP.  We did not want special
hardware or TCP gateways, did not want commercial TCP/IP software, and did
not want to spend much money.  We did want all the PCs on these networks
to boot up automatically via Boot ROMs in the Ethernet cards.

    Getting this all to work together was an amazingly complex task,
requiring weeks of work, many pieces of public domain software, and help
from many generous people.  As we were gathering information, several
people requested that we pass on the information we received if we could
make it work.  This document is written to make it easier for others to
follow the same path we did, and also serves as documentation to record
our sources of software for when we forget it all next week.

    In the steps which follow, most of the minor frustrating details of
obtaining and translating software are left out.  In general, having a
unix machine around is very useful, because you may need the programs
UUDECODE, UNCOMPRESS and TAR to unravel the file archives you obtain.  In
addition, having TAR and ARC on a IBM-compatible PC is important.

    The hosts mentioned as sources for software are merely the places
where we picked things up.  There are usually other alternative sources
available.

    If someone reading this (and trying to follow the same steps) gets
blocked because of the lack of a critical piece of software, send me mail
and I'll try to help.  We can make anything necessary available through
anonymous FTP on Internet or through file or mail servers on Bitnet.

    The story begins!

   1. We obtained copies of Novell Netware version 2.15, advanced and
      sft versions.

   2. We subscribed to the Novell special interest group bulletin
      board, [e-mail].  (This has proven absolutely
      essential!  Many thanks to the generous and hardworking people
      who make this list possible.)

   3. We formulated our goals and started asking for help.  This is a
      very current topic, and we quickly encountered a long message
      on July 19th giving very complete instructions on obtaining and
      using a "packet driver" (as opposed to a specific LAN hardware
      driver) which would allow LAN hardware to be shared by
      different programs.

          Who: Kelly McDonald at Brigham Young University
          Email: [e-mail]
          Host: sun.soe.clarkson.edu via anonymous ftp
          File: /pub/novell/novell.exe.uu

      The READ.ME file in this uuencoded, self-unpacking archive file
      gives instructions for creating a Netware shell for a client
      machine which would use the packet driver interface, thus
      allowing a properly configured TCP/IP based program to share
      access to the network hardware.  This archive file provided the
      Netware-specific part of the software.

   4. Next we picked up the packet driver code from Clarkson
      University, as instructed by the BYU documentation.  This
      distribution contains packet drivers for a number of Ethernet
      network boards, including the WD8003E board that we favor.  The
      distribution also includes some documentation on what packet
      drivers do and why you need them, so I won't go into that here.

          Host: sun.soe.clarkson.edu via anonymous ftp
          File: /pub/ka9q/drivers.arc

   5. Having settled the Netware end, we now needed a Telnet and FTP
      which had a packet driver interface.  We use and recommend NCSA
      Telnet, but their standard 2.2 version did not support a packet
      driver interface.  (Their 2.3 version does -- it's in beta test
      as of 10/12/89) We obtained NCSA Telnet 2.2TN, which is NCSA
      version 2.2 with many enhancements from Clarkson University.
      In addition to packet driver support (the critical part) it
      also supports TN3270 accsss (unimportant to us) and IP address
      assignment via BOOTP protocol (very useful to us!)

          Who: Brad Clements at Clarkson
          EMail: [e-mail]
          Host: Omnigate.clarkson.edu
          File: /pub/ncsa2.2tn/ncsabin.tar.Z

      You can also pick up PDTAR.EXE there for a MS-DOS TAR program,
      and ncsasrc.tar.Z for the complete telnet sources.

   6. We created Netware shells for our client machines using the
      packet driver interface.  This requires that you load the
      packet driver before running IPX.  In our case we used the
      program WD8003E.COM for the Western Digital Ethernet cards we
      use.  There are similar names for many other card-specific
      drivers.

      There is a catch!  The packet drivers talk the Ethernet version
      2 protocol, which is slightly different from the IEEE 802.3
      protocol that Novell uses on Ethernet.  So you need to use a
      program called ECONFIG to modify the Ethernet drivers on your
      Novell servers in order to tell them to talk Ethernet V2.
      protocols to their clients rather than the standard 802.3.
      This is an either-or decision -- if you choose the packet
      driver interface for some clients, you must use it for *all*
      clients of a server unless you install two Ethernet interfaces.
      (But this isn't the last word -- more later.)

   7. All was well, temporarily... we would run WD8003E in the login
      batch files of the client machines, then we could run IPX and
      NET4 to talk to the server just fine.  We could also use
      NCSA/Clarkson Telnet successfully and concurrently, simply
      telling it to use "PACKET" as the Ethernet device type.

      However, after the first flush of victory faded we had other
      problems.  Of course our boot proms no longer worked, because
      they use the same IEEE 802.3 protocols that we'd previously
      mentioned and we had ECONFIG'd the server so that it no longer
      understood that dialect.

      We diverted a lot of attention to using two cards in the
      server, one ECONFIG'd and one vanilla.  Well, that kind of
      worked, but left us with a messy situation -- you could either
      boot up automatically via the ROM (using standard Novell
      drivers) and stick to Novell software only, OR you could boot
      up with a floppy disk (using packet drivers) and then have
      Telnet and FTP available.  Yuck.

   8. So we asked for help again, and got swarms of responses.
      Several people had experimented with modifications to the
      packet driver code to change it to convert between 802.3 and
      Ethernet V.2 packet types -- very important, because your
      clients can then remain within the standard Novell world and
      your servers need not be ECONFIG'd.  Furthermore, the boot ROMs
      can (almost) work.

      But not quite.  Stripped of the technical details, it turns out
      that there is a difficulty negotiating the transfer of control
      of the Ethernet card from the ROM to the packet driver.  There
      were different approaches to this problem.

      The one we chose was courtesy of:

          Who: Andries Ruiter at the University of Groningan
          Email: [e-mail]

      Andries provided a modified packet driver (with source) for the
      Western Digital board which had two important enhancements:

         - Ethernet V.2 and 802.3 conversions

         - Postponement of the control handoff mentioned above
           (between the ROM and the packet driver) until the first
           Novell IPX packet is sent, which comes after NET4 is
           started.

   9. We were almost there, but not quite.  We still had problems
      with the ROM to PD handoff.  We could not complete the
      AUTOEXEC.BAT process within the remote reset file without
      aborting the login with some spurious "illegal switch" message
      during the NET4 process.  (For those vague on the remote reset
      files, they're simply a network-loaded version of a Novell boot
      floppy.  Stripped of frills, our AUTOEXEC.BAT file simply
      contained:)

          WD8003E 0X60 0X4 0X280 0XD000
          IPX
          NET4
          F:
          LOGIN GUEST

      However, the ROM-loaded version would not complete no matter
      what I tried.  So I broke it into two pieces, with
      manually-chained batch files requiring user interaction.

  10. Then we read about ROMREL, a program which was designed to
      address the ROM to PD handoff problem.  Basically, ROMREL
      simply releases the special BIOS hooks created by boot ROMS,
      and supposedly works for all cards.  It certainly works for WD
      cards.  A boot ROM works by creating a funny psuedo disk "A"
      which contains the contents of the network-loaded floppy.  So
      disk A is a memory disk until you run NET4, when it goes back
      to being a floppy.

      ROMREL is used in conjunction with a real RAMdisk which will
      stick around.  You use it by creating a RAMdisk in your
      CONFIG.SYS file, then having the AUTOEXEC.BAT file load all
      important files from the psuedo-A drive into the new RAMdrive.
      Then you tranfer to that drive, run ROMREL to get rid of the
      special BIOS hooks, and proceed swiftly and easily to complete
      the entire network login process with no errors.

          Who: Glen Marianko
          EMail: [e-mail]
          Host: Purdue University BBS at 317/494-0807
          File: ROMREL.COM and .DOC in Novell file area

  11. One remaining problem.  The Groningan modifications had
      postponed the initialization of the packet driver until after
      the first IPX packet had been processed.  Unfortunately, what
      this meant was that IPX was required to "turn on" the network
      -- running Telnet would not work until after IPX had been run.
      This wasn't a problem with the boot ROM machines, which all run
      IPX on startup, but it was a restriction for the staff hard
      disk machines which frequently didn't use the Novell server on
      a daily basis.

      We addressed this one by modifying the Groningan packet driver
      source to remove the second of Andrie's modifications.
      Actually, their version was a notch or two behind the standard
      packet driver source so we just borrowed their Ethernet v.2 <=>
      802.3 conversion code and moved it into the current Clarkson
      packet driver source.  The only module affected is the actual
      device-specific driver code (ie not the generic HEAD.ASM or
      TAIL.ASM files) and thus I only did it for the WD8003.

          Who: Doug Bigelow at Wesleyan University
          EMail:[e-mail]

  12. Finally, everything works.  Booting from the boot ROMS is quick
      and smooth, and all users can separately or simultaneously run
      IPX and Telnet regardless of the startup order.  It was a long
      hard road!


                             FUTURE PROBLEMS:

    Western Digital has released a new version of it's WD8003E card which
is smaller and is software configured using non-volatile memory.  No more
jumpers to fiddle with.  It's a nice card, but the driver has changed in
some subtle way.  The packet driver can still control the cards just fine,
thank goodness.  However, others can't.  NCSA Telnet, for example, will
crash the machine when told the device type is WD8003.  This works fine
with the old model Ethernet cards, and works with the new type if you use
the PACKET device type.  But the old driver with the new card crashes and
burns.

    Similarly, we have observed an odd problem with the standard Western
Digital boot ROMs for Novell Netware.  The new style cards boot with the
ROMS, but *v.e.r.y s.l.o.w.l.y* -- like two minutes instead of 15 seconds?
This happens while the remote reset file is being downloaded to the
machine, ie before any software driver gets loaded.  So far we've been
able to use only the old cards in our public ROM-booting machines, but
we've now run out -- so we hope someone figures this one out quickly.


                      APPENDIX -- REMOTE RESET FILES

    These are the batch files that we use for our network booting.  First,
the device drivers loaded via CONFIG.SYS:

    BREAK=ON
    BUFFERS=20
    FILES=40
    SHELL=COMMAND.COM /P /E:960
    DEVICE=ANSI.SYS
    DEVICE=RAMDRIVE.SYS 120 /E

    We use the DOS 4.X standard RAMDRIVE program to load up a 120 KB
drive.  It assigns the drive to the first vacant letter, hence it will be
drive C: in a two-floppy machine, or drive D: in a hard-disk machine.
This covers the options for us on our networked machines.  Others might
have to use a more exhaustive test than the one below in AUTOEXEC.BAT,
which figures out which drive is the RAMdisk.

    @echo off
    set configtel=x:config.tel
    prompt $p$g
    egasave 30 > nul
    dosedit > nul
    set rdisk=c:
    if exist c:\autoexec.bat set rdisk=d:
    copy *.com %rdisk% > nul
    copy go.bat %rdisk% > nul
    set comspec=%rdisk%command.com
    %rdisk%
    cls
    go

    Finally, we're on the RAMdisk and we proceed to release the ROM hooks
then activate the network via the GO.BAT batch job:

    @echo off
    romrel 3 > nul
    wd8003e 0x60 0x3 0x280 0xd000 > nul
    pdipx > nul
    net4 > nul
    f:
    echo $[2J$[7m You are now logged in as user GUEST.$[0m
    login guest